home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1006 < prev    next >
Text File  |  1995-07-25  |  31KB  |  1,125 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61. M. Rose & D. Cass                                               [Page 1]
  62.  
  63.  
  64.  
  65.  
  66. Network Working Group                    Marshall T. Rose, Dwight E. Cass
  67. Request for Comments: RFC 1006    Northrop Research and Technology Center
  68. Obsoletes: RFC 983                                               May 1987
  69.  
  70.  
  71.  
  72.                 ISO Transport Service on top of the TCP
  73.                                Version: 3
  74.  
  75.  
  76. Status of this Memo
  77.  
  78.    This memo specifies a standard for the Internet community. Hosts
  79.    on the Internet that choose to implement ISO transport services
  80.    on top of the TCP are expected to adopt and implement this
  81.    standard.  TCP port 102 is reserved for hosts which implement this
  82.    standard.  Distribution of this memo is unlimited.
  83.  
  84.    This memo specifies version 3 of the protocol and supersedes
  85.    [RFC983].  Changes between the protocol as described in Request for
  86.    Comments 983 and this memo are minor, but are unfortunately
  87.    incompatible.
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120. M. Rose & D. Cass                                               [Page 1]
  121.  
  122. RFC 1006                                                        May 1987
  123.  
  124.  
  125. 1.  Introduction and Philosophy
  126.  
  127.  
  128.       The Internet community has a well-developed, mature set of
  129.       transport and internetwork protocols (TCP/IP), which are quite
  130.       successful in offering network and transport services to
  131.       end-users. The CCITT and the ISO have defined various session,
  132.       presentation, and application recommendations which have been
  133.       adopted by the international community and numerous vendors.
  134.       To the largest extent possible, it is desirable to offer these
  135.       higher level directly in the ARPA Internet, without disrupting
  136.       existing facilities.  This permits users to develop expertise
  137.       with ISO and CCITT applications which previously were not
  138.       available in the ARPA Internet.  It also permits a more
  139.       graceful convergence and transition strategy from
  140.       TCP/IP-based networks to ISO-based networks in the
  141.       medium-and long-term.
  142.  
  143.       There are two basic approaches which can be taken when "porting"
  144.       an ISO or CCITT application to a TCP/IP environment.  One
  145.       approach is to port each individual application separately,
  146.       developing local protocols on top of the TCP.  Although this is
  147.       useful in the short-term (since special-purpose interfaces to the
  148.       TCP can be developed quickly), it lacks generality.
  149.  
  150.       A second approach is based on the observation that both the ARPA
  151.       Internet protocol suite and the ISO protocol suite are both
  152.       layered systems (though the former uses layering from a more
  153.       pragmatic perspective).  A key aspect of the layering principle
  154.       is that of layer-independence.  Although this section is
  155.       redundant for most readers, a slight bit of background material
  156.       is necessary to introduce this concept.
  157.  
  158.       Externally, a layer is defined by two definitions:
  159.  
  160.          a service-offered definition, which describes the services
  161.          provided by the layer and the interfaces it provides to
  162.          access those services; and,
  163.  
  164.          a service-required definitions, which describes the services
  165.          used by the layer and the interfaces it uses to access those
  166.          services.
  167.  
  168.       Collectively, all of the entities in the network which co-operate
  169.       to provide the service are known as the service-provider.
  170.       Individually, each of these entities is known as a service-peer.
  171.  
  172.       Internally, a layer is defined by one definition:
  173.  
  174.           a protocol definition, which describes the rules which each
  175.           service-peer uses when communicating with other service-peers.
  176.  
  177.  
  178.  
  179. M. Rose & D. Cass                                               [Page 2]
  180.  
  181. RFC 1006                                                        May 1987
  182.  
  183.  
  184.       Putting all this together, the service-provider uses the protocol
  185.       and services from the layer below to offer the its service to the
  186.       layer above.  Protocol verification, for instance, deals with
  187.       proving that this in fact happens (and is also a fertile field
  188.       for many Ph.D. dissertations in computer science).
  189.  
  190.       The concept of layer-independence quite simply is:
  191.  
  192.           IF one preserves the services offered by the service-provider
  193.  
  194.           THEN the service-user is completely naive with respect to the
  195.           protocol which the service-peers use
  196.  
  197.  
  198.       For the purposes of this memo, we will use the layer-independence
  199.       to define a Transport Service Access Point (TSAP) which appears
  200.       to be identical to the services and interfaces offered by the
  201.       ISO/CCITT TSAP (as defined in [ISO8072]), but we will in fact
  202.       implement the ISO TP0 protocol on top of TCP/IP (as defined in
  203.       [RFC793,RFC791]), not on top of the the ISO/CCITT network
  204.       protocol.  Since the transport class 0 protocol is used over the
  205.       TCP/IP connection, it achieves identical functionality as
  206.       transport class 4.  Hence, ISO/CCITT higher level layers (all
  207.       session, presentation, and application entities) can operate
  208.       fully without knowledge of the fact that they are running on a
  209.       TCP/IP internetwork.
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238. M. Rose & D. Cass                                               [Page 3]
  239.  
  240. RFC 1006                                                        May 1987
  241.  
  242.  
  243. 2.  Motivation
  244.  
  245.  
  246.       In migrating from the use of TCP/IP to the ISO protocols, there
  247.       are several strategies that one might undertake.  This memo was
  248.       written with one particular strategy in mind.
  249.  
  250.       The particular migration strategy which this memo uses is based
  251.       on the notion of gatewaying between the TCP/IP and ISO protocol
  252.       suites at the transport layer.  There are two strong arguments
  253.       for this approach:
  254.  
  255.       1.  Experience teaches us that it takes just as long to get good
  256.       implementations of the lower level protocols as it takes to get
  257.       implementations of the higher level ones.  In particular, it has
  258.       been observed that there is still a lot of work being done at the
  259.       ISO network and transport layers.  As a result, implementations
  260.       of protocols above these layers are not being aggressively
  261.       pursued. Thus, something must be done "now" to provide a medium
  262.       in which the higher level protocols can be developed.  Since
  263.       TCP/IP is mature, and essentially provides identical
  264.       functionality, it is an ideal medium to support this development.
  265.  
  266.       2.  Implementation of gateways at the IP and ISO IP layers are
  267.       probably not of general use in the long term.  In effect, this
  268.       would require each Internet host to support both TP4 and TCP.
  269.       As such, a better strategy is to implement a graceful migration
  270.       path from TCP/IP to ISO protocols for the ARPA Internet when the
  271.       ISO protocols have matured sufficiently.
  272.  
  273.       Both of these arguments indicate that gatewaying should occur at
  274.       or above the transport layer service access point.  Further, the
  275.       first argument suggests that the best approach is to perform the
  276.       gatewaying exactly AT the transport service access point to
  277.       maximize the number of ISO layers which can be developed.
  278.  
  279.         NOTE:     This memo does not intend to act as a migration or
  280.                   intercept document.  It is intended ONLY to meet the
  281.                   needs discussed above.  However, it would not be
  282.                   unexpected that the protocol described in this memo
  283.                   might form part of an overall transition plan.  The
  284.                   description of such a plan however is COMPLETELY
  285.                   beyond the scope of this memo.
  286.  
  287.       Finally, in general, building gateways between other layers in the
  288.       TCP/IP and ISO protocol suites is problematic, at best.
  289.  
  290.       To summarize: the primary motivation for the standard described in
  291.       this memo is to facilitate the process of gaining experience with
  292.       higher-level ISO protocols (session, presentation, and
  293.       application). The stability and maturity of TCP/IP are ideal for
  294.  
  295.  
  296.  
  297. M. Rose & D. Cass                                               [Page 4]
  298.  
  299. RFC 1006                                                        May 1987
  300.  
  301.  
  302.       providing solid transport services independent of actual
  303.       implementation.
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356. M. Rose & D. Cass                                               [Page 5]
  357.  
  358. RFC 1006                                                        May 1987
  359.  
  360.  
  361. 3.  The Model
  362.  
  363.  
  364.       The [ISO8072] standard describes the ISO transport service
  365.       definition, henceforth called TP.
  366.  
  367.           ASIDE:    This memo references the ISO specifications rather
  368.                     than the CCITT recommendations.  The differences
  369.                     between these parallel standards are quite small,
  370.                     and can be ignored, with respect to this memo,
  371.                     without loss of generality.  To provide the reader
  372.                     with the relationships:
  373.  
  374.                          Transport service    [ISO8072]       [X.214]
  375.                          Transport protocol   [ISO8073]       [X.224]
  376.                          Session protocol     [ISO8327]       [X.225]
  377.  
  378.  
  379.       The ISO transport service definition describes the services
  380.       offered by the TS-provider (transport service) and the interfaces
  381.       used to access those services.  This memo focuses on how the ARPA
  382.       Transmission Control Protocol (TCP) [RFC793] can be used to offer
  383.       the services and provide the interfaces.
  384.  
  385.  
  386.       +-----------+                                       +-----------+
  387.       |  TS-user  |                                       |  TS-user  |
  388.       +-----------+                                       +-----------+
  389.            |                                                     |
  390.            | TSAP interface                       TSAP interface |
  391.            |  [ISO8072]                                          |
  392.            |                                                     |
  393.       +----------+   ISO Transport Services on the TCP     +----------+
  394.       |  client  |-----------------------------------------|  server  |
  395.       +----------+              (this memo)                +----------+
  396.            |                                                     |
  397.            | TCP interface                         TCP interface |
  398.            |  [RFC793]                                           |
  399.            |                                                     |
  400.  
  401.  
  402.       For expository purposes, the following abbreviations are used:
  403.  
  404.          TS-peer      a process which implements the protocol described
  405.                       by this memo
  406.  
  407.          TS-user      a process talking using the services of a TS-peer
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415. M. Rose & D. Cass                                               [Page 6]
  416.  
  417. RFC 1006                                                        May 1987
  418.  
  419.  
  420.          TS-provider  the black-box entity implementing the protocol
  421.                       described by this memo
  422.  
  423.  
  424.       For the purposes of this memo, which describes version 2 of the
  425.       TSAP protocol, all aspects of [ISO8072] are supported with one
  426.       exception:
  427.  
  428.           Quality of Service parameters
  429.  
  430.  
  431.       In the spirit of CCITT, this is left "for further study".  A
  432.       future version of the protocol will most likely support the QOS
  433.       parameters for TP by mapping these onto various TCP parameters.
  434.  
  435.       The ISO standards do not specify the format of a session port
  436.       (termed a TSAP ID).  This memo mandates the use of the GOSIP
  437.       specification [GOSIP86] for the interpretation of this field.
  438.       (Please refer to Section 5.2, entitled "UPPER LAYERS ADDRESSING".)
  439.  
  440.       Finally, the ISO TSAP is fundamentally symmetric in behavior.
  441.       There is no underlying client/server model.  Instead of a server
  442.       listening on a well-known port, when a connection is established,
  443.       the TS-provider generates an INDICATION event which, presumably
  444.       the TS-user catches and acts upon.  Although this might be
  445.       implemented by having a server "listen" by hanging on the
  446.       INDICATION event, from the perspective of the ISO TSAP, all TS-
  447.       users just sit around in the IDLE state until they either generate
  448.       a REQUEST or accept an INDICATION.
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474. M. Rose & D. Cass                                               [Page 7]
  475.  
  476. RFC 1006                                                        May 1987
  477.  
  478.  
  479. 4.  The Primitives
  480.  
  481.  
  482.       The protocol assumes that the TCP[RFC793] offers the following
  483.       service primitives:
  484.  
  485.                                     Events
  486.  
  487.          connected       - open succeeded (either ACTIVE or PASSIVE)
  488.  
  489.          connect fails   - ACTIVE open failed
  490.  
  491.          data ready      - data can be read from the connection
  492.  
  493.          errored         - the connection has errored and is now closed
  494.  
  495.          closed          - an orderly disconnection has started
  496.  
  497.                                      Actions
  498.  
  499.          listen on port  - PASSIVE open on the given port
  500.  
  501.          open port       - ACTIVE open to the given port
  502.  
  503.          read data       - data is read from the connection
  504.  
  505.          send data       - data is sent on the connection
  506.  
  507.          close           - the connection is closed (pending data is
  508.                            sent)
  509.  
  510.  
  511. This memo describes how to use these services to emulate the following
  512. service primitives, which are required by [ISO8073]:
  513.  
  514.                                  Events
  515.  
  516.          N-CONNECT.INDICATION
  517.                           - An NS-user (responder) is notified that
  518.                             connection establishment is in progress
  519.  
  520.  
  521.          N-CONNECT.CONFIRMATION
  522.                           - An NS-user (responder) is notified that
  523.                             the connection has been established
  524.  
  525.          N-DATA.INDICATION
  526.                           - An NS-user is notified that data can be
  527.                             read from the connection
  528.  
  529.  
  530.  
  531.  
  532.  
  533. M. Rose & D. Cass                                               [Page 8]
  534.  
  535. RFC 1006                                                        May 1987
  536.  
  537.  
  538.          N-DISCONNECT.INDICATION
  539.                           - An NS-user is notified that the connection
  540.                             is closed
  541.  
  542.                                 Actions
  543.  
  544.          N-CONNECT.REQUEST
  545.                           - An NS-user (initiator) indicates that it
  546.                             wants to establish a connection
  547.  
  548.          N-CONNECT.RESPONSE
  549.                           - An NS-user (responder) indicates that it
  550.                             will honor the request
  551.  
  552.          N-DATA.REQUEST   - An NS-user sends data
  553.  
  554.          N-DISCONNECT.REQUEST
  555.                           - An NS-user indicates that the connection
  556.                             is to be closed
  557.  
  558.       The protocol offers the following service primitives, as defined
  559.       in [ISO8072], to the TS-user:
  560.  
  561.                                     Events
  562.  
  563.          T-CONNECT.INDICATION
  564.                           - a TS-user (responder) is notified that
  565.                             connection establishment is in progress
  566.  
  567.          T-CONNECT.CONFIRMATION
  568.                           - a TS-user (initiator) is notified that the
  569.                             connection has been established
  570.  
  571.          T-DATA.INDICATION
  572.                           - a TS-user is notified that data can be read
  573.                             from the connection
  574.  
  575.          T-EXPEDITED DATA.INDICATION
  576.                           - a TS-user is notified that "expedited" data
  577.                             can be read from the connection
  578.  
  579.          T-DISCONNECT.INDICATION
  580.                           - a TS-user is notified that the connection
  581.                             is closed
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592. M. Rose & D. Cass                                               [Page 9]
  593.  
  594. RFC 1006                                                        May 1987
  595.  
  596.  
  597.                                 Actions
  598.  
  599.          T-CONNECT.REQUEST
  600.                           - a TS-user (initiator) indicates that it
  601.                             wants to establish a connection
  602.  
  603.          T-CONNECT.RESPONSE
  604.                           - a TS-user (responder) indicates that it
  605.                             will honor the request
  606.  
  607.          T-DATA.REQUEST   - a TS-user sends data
  608.  
  609.          T-EXPEDITED DATA.REQUEST
  610.                           - a TS-user sends "expedited" data
  611.  
  612.          T-DISCONNECT.REQUEST
  613.                           - a TS-user indicates that the connection
  614.                             is to be closed
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651. M. Rose & D. Cass                                              [Page 10]
  652.  
  653. RFC 1006                                                        May 1987
  654.  
  655.  
  656. 5.  The Protocol
  657.  
  658.  
  659.       The protocol specified by this memo is identical to the protocol
  660.       for ISO transport class 0, with the following exceptions:
  661.  
  662.             - for testing purposes, initial data may be exchanged
  663.               during connection establishment
  664.  
  665.             - for testing purposes, an expedited data service is
  666.               supported
  667.  
  668.             - for performance reasons, a much larger TSDU size is
  669.               supported
  670.  
  671.             - the network service used by the protocol is provided
  672.               by the TCP
  673.  
  674.  
  675.       The ISO transport protocol exchanges information between peers in
  676.       discrete units of information called transport protocol data units
  677.       (TPDUs).  The protocol defined in this memo encapsulates these
  678.       TPDUs in discrete units called TPKTs.  The structure of these
  679.       TPKTs and their relationship to TPDUs are discussed in the next
  680.       section.
  681.  
  682.       PRIMITIVES
  683.  
  684.          The mapping between the TCP service primitives and the service
  685.          primitives expected by transport class 0 are quite straight-
  686.          forward:
  687.  
  688.                    network service              TCP
  689.                    ---------------              ---
  690.                    CONNECTION ESTABLISHMENT
  691.  
  692.                        N-CONNECT.REQUEST        open completes
  693.  
  694.                        N-CONNECT.INDICATION     listen (PASSIVE open)
  695.                                                 finishes
  696.  
  697.                        N-CONNECT.RESPONSE       listen completes
  698.  
  699.                        N-CONNECT.CONFIRMATION   open (ACTIVE open)
  700.                                                 finishes
  701.  
  702.                    DATA TRANSFER
  703.  
  704.                        N-DATA.REQUEST           send data
  705.  
  706.                        N-DATA.INDICATION        data ready followed by
  707.  
  708.  
  709.  
  710. M. Rose & D. Cass                                              [Page 11]
  711.  
  712. RFC 1006                                                        May 1987
  713.  
  714.  
  715.                                                 read data
  716.  
  717.                    CONNECTION RELEASE
  718.  
  719.                        N-DISCONNECT.REQUEST     close
  720.  
  721.                        N-DISCONNECT.INDICATION  connection closes or
  722.                                                 errors
  723.  
  724.           Mapping parameters is also straight-forward:
  725.  
  726.                      network service             TCP
  727.                      ---------------             ---
  728.                      CONNECTION RELEASE
  729.  
  730.                          Called address          server's IP address
  731.                                                  (4 octets)
  732.  
  733.                          Calling address         client's IP address
  734.                                                  (4 octets)
  735.  
  736.                          all others              ignored
  737.  
  738.                       DATA TRANSFER
  739.  
  740.                          NS-user data (NSDU)     data
  741.  
  742.                       CONNECTION RELEASE
  743.  
  744.                          all parameters          ignored
  745.  
  746.  
  747.  
  748.       CONNECTION ESTABLISHMENT
  749.  
  750.           The elements of procedure used during connection establishment
  751.           are identical to those presented in [ISO8073], with three
  752.           exceptions.
  753.  
  754.           In order to facilitate testing, the connection request and
  755.           connection confirmation TPDUs may exchange initial user data,
  756.           using the user data fields of these TPDUs.
  757.  
  758.           In order to experiment with expedited data services, the
  759.           connection request and connection confirmation TPDUs may
  760.           negotiate the use of expedited data transfer using the
  761.           negotiation mechanism specified in [ISO8073] is used (e.g.,
  762.           setting the "use of transport expedited data transfer service"
  763.           bit in the "Additional Option Selection" variable part). The
  764.           default is not to use the transport expedited data transfer
  765.           service.
  766.  
  767.  
  768.  
  769. M. Rose & D. Cass                                              [Page 12]
  770.  
  771. RFC 1006                                                        May 1987
  772.  
  773.  
  774.           In order to achieve good performance, the default TPDU size is
  775.           65531 octets, instead of 128 octets.  In order to negotiate a
  776.           smaller (standard) TPDU size, the negotiation mechanism
  777.           specified in [ISO8073] is used (e.g., setting the desired bit
  778.           in the "TPDU Size" variable part).
  779.  
  780.           To perform an N-CONNECT.REQUEST action, the TS-peer performs
  781.           an active open to the desired IP address using TCP port 102.
  782.           When the TCP signals either success or failure, this results
  783.           in an N-CONNECT.INDICATION action.
  784.  
  785.           To await an N-CONNECT.INDICATION event, a server listens on
  786.           TCP port 102.  When a client successfully connects to this
  787.           port, the event occurs, and an implicit N-CONNECT.RESPONSE
  788.           action is performed.
  789.  
  790.               NOTE:      In most implementations, a single server will
  791.                          perpetually LISTEN on port 102, handing off
  792.                          connections as they are made
  793.  
  794. DATA TRANSFER
  795.  
  796.       The elements of procedure used during data transfer are identical
  797.       to those presented in [ISO8073], with one exception: expedited
  798.       data may be supported (if so negotiated during connection
  799.       establishment) by sending a modified ED TPDU (described below).
  800.       The TPDU is sent on the same TCP connection as all of the other
  801.       TPDUs. This method, while not faithful to the spirit of [ISO8072],
  802.       is true to the letter of the specification.
  803.  
  804.       To perform an N-DATA.REQUEST action, the TS-peer constructs the
  805.       desired TPKT and uses the TCP send data primitive.
  806.  
  807.       To trigger an N-DATA.INDICATION action, the TCP indicates that
  808.       data is ready and a TPKT is read using the TCP read data
  809.       primitive.
  810.  
  811. CONNECTION RELEASE
  812.  
  813.    To perform an N-DISCONNECT.REQUEST action, the TS-peer simply closes
  814.    the TCP connection.
  815.  
  816.    If the TCP informs the TS-peer that the connection has been closed or
  817.    has errored, this indicates an N-DISCONNECT.INDICATION event.
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828. M. Rose & D. Cass                                              [Page 13]
  829.  
  830. RFC 1006                                                        May 1987
  831.  
  832.  
  833. 6.  Packet Format
  834.  
  835.  
  836.       A fundamental difference between the TCP and the network service
  837.       expected by TP0 is that the TCP manages a continuous stream of
  838.       octets, with no explicit boundaries.  The TP0 expects information
  839.       to be sent and delivered in discrete objects termed network
  840.       service data units (NSDUs).  Although other classes of transport
  841.       may combine more than one TPDU inside a single NSDU, transport
  842.       class 0 does not use this facility.  Hence, an NSDU is identical
  843.       to a TPDU for the purposes of our discussion.
  844.  
  845.       The protocol described by this memo uses a simple packetization
  846.       scheme in order to delimit TPDUs.  Each packet, termed a TPKT, is
  847.       viewed as an object composed of an integral number of octets, of
  848.       variable length.
  849.  
  850.           NOTE:       For the purposes of presentation, these objects are
  851.                       shown as being 4 octets (32 bits wide).  This
  852.                       representation is an artifact of the style of this
  853.                       memo and should not be interpreted as requiring
  854.                       that a TPKT be a multiple of 4 octets in length.
  855.  
  856.       A TPKT consists of two parts:  a packet-header and a TPDU.  The
  857.       format of the header is constant regardless of the type of packet.
  858.       The format of the packet-header is as follows:
  859.  
  860.         0                   1                   2                   3
  861.         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  862.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  863.        |      vrsn     |    reserved   |          packet length        |
  864.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  865.  
  866.       where:
  867.  
  868.       vrsn                         8 bits
  869.  
  870.       This field is always 3 for the version of the protocol described in
  871.       this memo.
  872.  
  873.       packet length                16 bits (min=7, max=65535)
  874.  
  875.       This field contains the length of entire packet in octets,
  876.       including packet-header.  This permits a maximum TPDU size of
  877.       65531 octets.  Based on the size of the data transfer (DT) TPDU,
  878.       this permits a maximum TSDU size of 65524 octets.
  879.  
  880.       The format of the TPDU is defined in [ISO8073].  Note that only
  881.       TPDUs formatted for transport class 0 are exchanged (different
  882.       transport classes may use slightly different formats).
  883.  
  884.  
  885.  
  886.  
  887. M. Rose & D. Cass                                              [Page 14]
  888.  
  889. RFC 1006                                                        May 1987
  890.  
  891.  
  892.       To support expedited data, a non-standard TPDU, for expedited data
  893.       is permitted.  The format used for the ED TPDU is nearly identical
  894.       to the format for the normal data, DT, TPDU.  The only difference
  895.       is that the value used for the TPDU's code is ED, not DT:
  896.  
  897.        0                   1                   2                   3
  898.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  899.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  900.       | header length | code  |credit |TPDU-NR and EOT|   user data   |
  901.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  902.       |      ...      |      ...      |      ...      |      ...      |
  903.       |      ...      |      ...      |      ...      |      ...      |
  904.       |      ...      |      ...      |      ...      |      ...      |
  905.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  906.  
  907.       After the credit field (which is always ZERO on output and ignored
  908.       on input), there is one additional field prior to the user data.
  909.  
  910.       TPDU-NR and EOT         8 bits
  911.  
  912.       Bit 7 (the high-order bit, bit mask 1000 0000) indicates the end
  913.       of a TSDU.  All other bits should be ZERO on output and ignored on
  914.       input.
  915.  
  916.       Note that the TP specification limits the size of an expedited
  917.       transport service data unit (XSDU) to 16 octets.
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946. M. Rose & D. Cass                                              [Page 15]
  947.  
  948. RFC 1006                                                        May 1987
  949.  
  950.  
  951. 7.  Comments
  952.  
  953.  
  954.       Since the release of RFC983 in April of 1986, we have gained much
  955.       experience in using ISO transport services on top of the TCP.  In
  956.       September of 1986, we introduced the use of version 2 of the
  957.       protocol, based mostly on comments from the community.
  958.  
  959.       In January of 1987, we observed that the differences between
  960.       version 2 of the protocol and the actual transport class 0
  961.       definition were actually quite small.  In retrospect, this
  962.       realization took much longer than it should have:  TP0 is is meant
  963.       to run over a reliable network service, e.g., X.25. The TCP can be
  964.       used to provide a service of this type, and, if no one complains
  965.       too loudly, one could state that this memo really just describes a
  966.       method for encapsulating TPO inside of TCP!
  967.  
  968.       The changes in going from version 1 of the protocol to version 2
  969.       and then to version 3 are all relatively small. Initially, in
  970.       describing version 1, we decided to use the TPDU formats from the
  971.       ISO transport protocol.  This naturally led to the evolution
  972.       described above.
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005. M. Rose & D. Cass                                              [Page 16]
  1006.  
  1007. RFC 1006                                                        May 1987
  1008.  
  1009.  
  1010. 8. References
  1011.  
  1012.  
  1013.    [GOSIP86]    The U.S. Government OSI User's Committee.
  1014.                 "Government Open Systems Interconnection Procurement
  1015.                 (GOSIP) Specification for Fiscal years 1987 and
  1016.                 1988." (December, 1986) [draft status]
  1017.  
  1018.    [ISO8072]    ISO.
  1019.                 "International Standard 8072.  Information Processing
  1020.                 Systems -- Open Systems Interconnection: Transport
  1021.                 Service Definition."
  1022.                 (June, 1984)
  1023.  
  1024.    [ISO8073]    ISO.
  1025.                 "International Standard 8073.  Information Processing
  1026.                 Systems -- Open Systems Interconnection: Transport
  1027.                 Protocol Specification."
  1028.                 (June, 1984)
  1029.  
  1030.    [ISO8327]    ISO.
  1031.                 "International Standard 8327.  Information Processing
  1032.                 Systems -- Open Systems Interconnection: Session
  1033.                 Protocol Specification."
  1034.                 (June, 1984)
  1035.  
  1036.    [RFC791]     Internet Protocol.
  1037.                 Request for Comments 791 (MILSTD 1777)
  1038.                 (September, 1981)
  1039.  
  1040.    [RFC793]     Transmission Control Protocol.
  1041.                 Request for Comments 793 (MILSTD 1778)
  1042.                 (September, 1981)
  1043.  
  1044.    [RFC983]     ISO Transport Services on Top of the TCP.
  1045.                 Request for Comments 983
  1046.                 (April, 1986)
  1047.  
  1048.    [X.214]      CCITT.
  1049.                 "Recommendation X.214.  Transport Service Definitions
  1050.                 for Open Systems Interconnection (OSI) for CCITT
  1051.                 Applications."
  1052.                 (October, 1984)
  1053.  
  1054.    [X.224]      CCITT.
  1055.                 "Recommendation X.224.  Transport Protocol
  1056.                 Specification for Open Systems Interconnection (OSI)
  1057.                 for CCITT Applications." (October, 1984)
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064. M. Rose & D. Cass                                              [Page 17]
  1065.  
  1066. RFC 1006                                                        May 1987
  1067.  
  1068.  
  1069.    [X.225]      CCITT.
  1070.                 "Recommendation X.225.  Session Protocol Specification
  1071.                 for Open Systems Interconnection (OSI) for CCITT
  1072.                 Applications."
  1073.                 (October, 1984)
  1074.  
  1075.  
  1076.  
  1077.  
  1078.  
  1079.  
  1080.  
  1081.  
  1082.  
  1083.  
  1084.  
  1085.  
  1086.  
  1087.  
  1088.  
  1089.  
  1090.  
  1091.  
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122.  
  1123. M. Rose & D. Cass                                              [Page 18]
  1124.  
  1125.